feat(updates): add one-click upgrade experience - #840

Reviewable diff: +917/-8 across 5 files (excludes generated, test, and story files).

Summary

Adds the one-click upgrade workflow to Settings > Updates: exact-version confirmation, RC warnings, durable progress, expected restart recovery, failure guidance, and success reload. The normal application shell remains intentionally passive—it only advertises an available version and routes operators to Settings—while unsupported hosts retain the release-specific manual install command.

Stack: #841 → #842 → #843 → #844 → #845 → #835 → #836 → #837 → #838 → #839 → #840. This is 6/6 of the one-click phase and the diff is relative to #839. The merged ancestors provide release discovery, permission-gated APIs, durable host execution, and the passive update indicator; #839 installs that executor on supported hosts. Host mutation is intentionally out of scope here, and progress is intentionally not tracked across every Fleet view.

How it works

The passive version pill navigates an authorized operator to /settings/updates. The route loads the current eligible release, capability, and manual command, while separately checking durable updater status so an operation started in another tab or recovered after navigation takes precedence over a newer offer. A one-click action appears only when Fleet reports a reachable executor; confirmation sends only the exact eligible version, and fleetd revalidates it before host mutation.

During an operation the route uses completion-based polling, preserves the last phase through the expected Fleet restart, and recovers host state when the operator returns. Ambiguous trigger outcomes keep competing controls locked. If the executor remains unreachable after the bounded reconciliation window, the manual command stays locked until the operator explicitly confirms on-host that no upgrade is running; a reachable executor reporting no matching operation instead refreshes the eligible release before retry.

flowchart LR
  S["Passive version pill"] --> R["Settings > Updates"]
  R --> U["GetUpdateStatus: release, capability, manual command"]
  R --> O["GetUpgradeStatus: durable host operation"]
  U --> C{"Executor reachable?"}
  C -->|"yes"| X["Confirm exact target"]
  C -->|"no"| M["Copy manual install command"]
  X --> T["TriggerUpgrade(target version)"]
  T --> P["Route-owned progress and recovery"]
  O --> P
  P --> F["Failure details or explicit manual fallback"]
  P --> D["Success and reload"]

sequenceDiagram
  participant U as "Authorized operator"
  participant S as "Fleet shell"
  participant R as "Updates route"
  participant F as "fleetd"
  participant X as "Host updater"

  S->>F: "Discover eligible version"
  F-->>S: "Version-only indicator"
  U->>S: "Open update"
  S->>R: "Navigate to /settings/updates"
  R->>F: "GetUpdateStatus + GetUpgradeStatus"
  F-->>R: "Offer, capability, durable operation"
  U->>R: "Confirm exact target"
  R->>F: "TriggerUpgrade(target version)"
  F->>X: "Start validated operation"
  R-->>F: "Poll without overlap"
  opt "Operator leaves the route"
    U->>R: "Return later"
    R->>F: "Recover durable status"
  end
  F-->>R: "Active, failed, or succeeded"
  R-->>U: "Progress, recovery, or reload"

Areas of the code involved

Key technical decisions & trade-offs

• Settings owns confirmation and progress; the shell keeps only a passive link, avoiding lifecycle state across every route.
• Durable host status is authoritative; browser session storage records only which terminal result belongs to this tab and survives route remounts.
• Polls schedule only after the prior request completes, with bounded RPCs, avoiding overlapping requests during a restart.
• An active host operation supersedes a newer release offer; the UI never exposes two competing targets.
• Unknown trigger outcomes fail closed. Manual fallback requires explicit host confirmation after the bounded wait rather than silently unlocking a potentially overlapping install.
• Failed operations retain the established manual command and expose the host log/recovery command; automatic rollback remains out of scope because migrations are forward-only.

Testing & validation

• 79 focused Vitest cases passed across Settings integration, upgrade lifecycle, modal states, the passive indicator, and AppLayout behavior.
• Full client ESLint and TypeScript typechecking passed; npm run build:protoFleet passed the production Vite build.
• The full local unit run completed 4,013 tests successfully; one unrelated QR/WASM suite could not load through this worktree's symlinked node_modules path and is left to the normal CI checkout.
• Pre-commit formatting and pre-push typecheck hooks passed.
• Real systemd/rootful-Docker activation is intentionally covered by the preceding host PRs rather than browser unit tests.